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IP security is provided in a virtual private network using 
network address translation (NAT) by performing one or a 
combination-of the three types of VPN NAT, including VPN 
NAT type a outbound source IP NAT, VPN NAT type c 
inbound source IP NAT, and VPN NAT type d inbound 
destination IP NAT. This involves dynamically generating 
NAT rules and associating them with the manual or dynami- 
cally generated (IKE) Security Associations, before begin- 
ning IP security that uses the Security Associations. Then, as 
IP Sec is performed on outbound and inbound datagrams, 
the NAT function is also performed. 
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SYSTEM AND METHOD FOR NETWORK will fail, due to the changed IP source address (because it 

ADDRESS TRANSLATION INTEGRATION was not the address used to negotiate the security 

WITH IP SECURITY association). So, even the transport mode ESP case fails. 

Simply making NAT and IP Sec mutually exclusive is not 

CROSS REFERENCES TO RELATED 5 the solution sought by the art. NAT is being deployed widely 

APPLICATIONS because it solves many problems, such as: masks global 

¥TO ... _ , address changes, lowers address utilization, lowers ISP 

U.S. patent applications Ser. No. 09/239,693, entitled • u j n 1 ,1 u • • ♦/ 1 u . v ♦ 

o j w l j r w o • support burden, allows load sharing as virtual hosts. Yet, 

System and Method for Managing Security Objects, now ™ . . , . rrreatest sinnle threat to securitv 

U.S. Pat. No. 6,330,562; Ser. No 09/240,718, entitled "Sys- in * ™ d * S , ^7 h , ^* ,7^ ™ 3 

* w . „ r ^ tm / In 10 integration being deployed in the Internet today. This NAT 

tern and Method for Dynamic Macro Placement of IP -Ti » • ■ • ui « « j • u** . u c 

r> n , „ c kt nnmrnznA **ti j uc . problem , as it is invariably termed, ts architecturally fun- 

Connection Filters : Ser. No. 09/239,694, entitled System \ . . v , , r j - tc 

1 » . 1 j f * iii * ftnP 7 damental. Yet, legacy applications and services (for 

and Method for-Dynamic Micro Placement of IP Connection „ , iU j 1 1 <T m * a\ n ™ . 

„, „ , „ ' T ™ . , , , example, those developed for IP version 4) will continue to 

Filters ; and Ser. No. 09/240,483, entitled "System and 1 • . r 1 • 1 1 r 

w 1 j * X . w ' / ri , a long co-existence as applications and services develop for 

Method for Central Management of Connections in a-Virtual JS ip vefsion fi c uentl there is a t need in the art for 

Pnvate Network, filed concurrently herewith are assigned to idin NAT and IP Sec coex istence, at least in selected 

the same assignee hereof and contain subject matter related, situati and t0 do so without introducing se rious configu . 

in, certain respects, to the subject matter of the present . , _ 

' .. . ' .. ,.„ J , , , ,- ration problems, 

application. The above-idenUfied patent apphcaUons are A WN connection tetWBen two address domains can 

incorporated herein by reference. M ^ ^ effcct Qf d;rect]y connecting lhe two domainS) 

BACKGROUND OF THE INVENTION which most likely will not been planned to be connected. 

Hence increased use of VPNs is likely to increase address 

1. Technical Field of the Invention conflicts. It is also understood that VPNs redefine network 

This invention pertains to security over virtual private visibility and increase the likelihood of address collision 

network (VPN) connections. More particularly, it relates to 25 when traversing NATs, Address management in the hidden 

VPN NAT, or concurrent use of network address translation space behind NATs will become a significant burden. There 

(NAT) and IP Security (IPSec) protocols. is, therefore, a need in the art to ameliorate that burden. 

2 Background Art ' l * s an °4 ect °f tne invention to provide an improved 

' , A ^ , . ■ , . * , , . system and method for concurrently implementing both 

Network Address Translation (NAO, widely deployed in 3Q Ne(work Address Translation (NAr) and , p Securit (Ip 

Internet and in companies connecting to the Internet, causes « \ 

problems for IP Security. In fact, NAT breaks IP Security (IP & , . 4 . . A . „ 

0 ^ . ■ v, >^ «• l c / X.- t_ cl 11 u i V It is a further object of the invention to provide a system 
Sec). That is, NAT is the feature which finally breaks the , , c J , . • , , , A J c Tn 

7 \ , _ , ,^ . f , , , 1 , and method for solving the increased likelyhood of IP 

semantic overload of the IP address as both a locator, and the «• ♦ • u * • a. c 1 • . 

. .„ „ A , , , , address conflicts mherent in the use of a virtual pnvate 

end-point identifier . As a result, two hosts cannot establish 35 networ ^ (ypK) 

an IP Sec connection if there is a NAT system in between. T . \ , . . ^ 4 . . 4 . , 

3 It is a further object of the invention to provide a system 

1 here are two reasons why. and melhod for enabUng ulilization of V PNs without requit- 

First, the IP traffic that flows between the two hosts (for ing re . a ddressing a domain (a expensive alternative), 

the IP Sec connection) will have AH or ESP applied. With It is a ^ nhGT object of lne invenlion t0 provide a syslern 

respect to ESP in tunnel mode, the IP address that needs to 40 and method for VPN NAX which is acc0 mplished entirely in 

be translated is inside the ESP tunnel and is encrypted. It is, the Ip Sec gateway without require changes in domain hosts 

therefore, unavailable to NAT. With respect to AH in trans- It is a ^ nh6r object of the inven tion to provide a system 

port or tunnel mode, the IP address that needs to be trans- and method for yp N NAX which requires no, or only minor 

lated is visible in NAT, but the AH authentication includes cha nges to routing, in each connected domain, 

it. Therefore, changing the IP address will break the authen- 45 h is a ^he,. ob j ect of the i nve ntion to provide a system 

tication at the remote end of the IP Sec connection. With and met hod for VPN NAT which is simple to configure, 

respect to ESP in transport mode, even if ESP is used with It fc a object of the i nven tion to provide a solution 

authentication, the IP address is available to NAT. But, if the to lhe address coUision problems caused by VPNs. 
IP address is changed, the IP Sec connection breaks due to 

the breaking of authentication at the remote end of the IP Sec 50 SUMMARY OF THE INVENTION 

connection. j n accordance w jth the invention, IP security is provided 

Second, even if the IP traffic for the IP Sec connection in a virtual private network using network address transla- 

could be translated, it would fail because the IP Sec con- tion (NAT) by performing one or a combination of the three 

nection is based on Security Associations which contain the types of VPN NAT. This involves dynamically generating 

two host IP addresses. These are fundamental to the Security 55 NAT rules and associating them with the manual or dynami- 

Association architecture, in that the inbound IP Sec, on the cally generated (IKE) Security Associations, before begin- 

host where decrypting (or authentication) is to occur, must n ing IP security that uses the Security Associations. Then, as 

be uniquely determined by the triple: ip Sec is performed on outbound and inbound datagrams, 

{destination IP addr, SPI, IP Sec protocol}. the NAT ftinction is also performed. 

For example, given hosts A & W, assume NAT is applied to 60 Other features and advantages of this invention will 

an IP datagram (a generic term for bytes that go on the wire) become apparent from the following detailed description of 

with ESP in transport mode that is going from A to W. Hence the presently preferred embodiment of the invention, taken 

the IP source address is changed. Upon arrival at W, the m conjunction with the accompanying drawings, 
packet will probably be decrypted successfully since that 

doesn't depend on IP source address (which was in 65 BRIEF DESCRIPTION OF THE DRAWINGS 

plaintext — not tunneled). If strictly implemented however, FIG. 1 is a flow diagram of the VPN NAT method of the 

the inbound SPD checking which should follow decrypting preferred embodiment of the invention. 
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FIG. 2 illustrates typical IP Sec scenarios and associated 
VPN NAT pools. 

FIG. 3 illustrates static NAT, the simplest conventional 
NAT. 

FIG. 4 illustrates masquerade NAT, a type of conventional 5 
NAT. 

FIG. 5 illustrates VPN NAT, type a: IDci translated for 
initiator-mode conversations. 

FIG. 6 illustrates VPN NAT, type c: IDci translated for 
responder-mode conversations. 

FIG. 7 illustrates VPN NAT, type d: IDcr translated for 
responder-mode conversations. 

BEST MODE FOR CARRYING OUT THE 
INVENTION 

In accordance with the preferred embodiment of the 
invention, the NAT problem is addressed through two func- 
tions: VPN NAT, and Prefer IP Sec. 

Pursuant to Prefer IP Sec, to avoid dysfunctional IP Sec ^ 
connections with the accidental use of HIDE and MAP NAT 
rules (aka conventional-NAT), AH or ESP is checked for 
during conventional NAT. If a given NAT rule would apply 
to the IP packet, except for the AH or ESP header, address 
translation will not be done. This applies to inbound and ^ 
outbound NAT. So, the effect is that for conventional NAT 
(versus VPN NAT for IP Sec, or IP Sec NAT), preference is 
given to IP Sec, IP Sec overrides conventional NAT. 

Since it is not known at the time the NAT rules are loaded 
whether or not any IP Sec connections might conflict 3Q 
(dynamic IP for example), checking for such problems 
cannot be done until actual NAT processing in SLIC. User 
visibility to these actions is provided, if journaling is on for 
the rule, by indicating in a journal entry that a NAT rule fit 
the datagram, but was not done due to IP Sec. In addition, 35 
LIC information logging of these actions may be provided 
for some limited- number of occurrences per conventional 
NAT rule. Similarly, a message per connection, rather than 
per occurrence, may be provided in a connection manager 
job log or in a connection journal. 4Q 

Pursuant to the present invention, referred to as VPN 
NAT, to allow NAT to be used with IP Sec at the IP Sec 
gateway, customers retain private internal IP addresses and 
increased address collision is avoided by having IP Sec 
connections begin and end at the IP Sec gateway. 45 

In accordance with the preferred embodiment of the 
invention, virtual private networks (VPN) are provided in 
both initiator and responder modes with an integrated NAT 
function. Security associations are negotiated using the 
proper external (NAT rhs) IP addresses, and the NATing of 50 
corresponding internal (NAT lhs) IP addresses is done by 
generated NAT rules, in sync with connection load to IPsec 
and IPSec processing in SLIC. Inbound-source IP addresses 
are translated, as well as the usual source IP address NAT 
don outbound, (with corresponding translation of destination 55 
IP address on inbound). 

Referring to FIG. 1, the method of the preferred embodi- 
ment of the invention for executing VPN NAT includes in 
step 20 configuring connections that require NAT, in step 22 
defining IPSec NAT pools, in step 24 starting initiator mode eo 
connections, in step 26 starting responder mode connections 
(these are generally started at the other end of the 
connection), in step 28 processing SA pair updates, and in 
step 30 ending the connections. (A NAT pool is a set of IP 
addresses.) Each of these steps is further explained below. $5 

In step 20, the user decides on and configures the con- 
nections that will require NAT. This is logically equivalent 



to writing NAT rules. The four cases to be considered in 
doing so are depicted in Table 1. 

TABLE 1 



TYPES OF VPN NAT 



IDci 



IDcr 



initiator 


type a. NAT internal 


type b.n/a, because 


mode 


address, IP sre on 


is externally defined. 




outbound, IP dest 






on inbound. 




responder 


type c.NAT external 


type d.NAT internal 


mode 


address, IP sre on 


address, IP dest on 




inbound, IP dest 


inbound, IP sre on 




on outbound. 


outbound 



When specifying a specific instance of NAT in, for 
example, an IP Sec Policy database, the user makes a yes/no 
decision in, say, a-check-box. Responder mode NAT flags 
IDci and IDcr may be part of the connection definition. The 
initiator mode flag may be part of the user client pair, 
associated with a 'local client ID' (only). The responder IDci 
and IDcr NAT flags can be set independently. Both are 
relevant only if connection definition has external initializa- 
tion mode. 

In all cases, if the NAT flag is 'on', the corresponding 
granularity value should be *s' (scalar) in the connection 
definition. 

Referring to FIG. 2, the manner in which VPN NAT IP 
pools relate to network scenarios is shown. Lines 34 and 36 
represent IP Sec connections between gateways (GW) 42, 44 
and 46 on Internet 40. NAT pools 52, 54 for types a and c 
are independently associated with each remote ID (gateway 
42, 44, 46). For type d VPN NAT, a single pool 50 may 
defined for global IP address that the VPN NAT gateway 42 
owns. In this.example, all three internal networks 56, 58 and 
60 use the same 10.*.*.* addresses space. This provides the 
initial value and motivation for VPN NAT: IP Sec tunnels 
(aka connections) between these internal networks 56, 58, 
60 has a logical effect combining them. This cannot be done, 
in general, without address conflict. VPN NAT provides the 
solution to the problem presented to gateway (Gw 1) 42 
when it needs to do business with hosts behind gateways Gw 
Q 44 and Gw Y !46 on internal networks 60 and 58, 
respectively. 

In step 22, the user defines a set (in pools 50, 52 and 54) 
of IP addresses that are available for the exclusive use of the 
VPN NAT function. Each pool is-preferably definable as a 
range of IP address, and is naturally associated with remote 
ID and local ID IP Sec Policy database entities. That is, for 
each remote ID DB entry and also for each local ID DB 
entry, the user may optionally specify two IP addresses. 

Referring to Table 2, the different meanings of each flavor 
of VPN NAT motivating the different pools are set forth. 
Although specified on a per remote ID or local ID basis, the 
pools may be managed as three distinct groups of IP 
addresses. This allows the user to specify, for example, the 
same range for multiple remote ID's. The letters a, c and d 
correspond to the VPN NAT types (Table 1). The column 
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'lr?' means locally routable (as distinguished from globally 
routable.) 

TABLE 2 





IP SEC NAT POOLS 






Effective generated 


lr sec fNAl pools 


Pool purpose 


outbound NAT rule lr? 


a. 1 .* 


1 . Hide own IP 


"MAP srcIP TO <value yes 


tions, translate 


addresses from 


r „ l ty VT AT* 

from pool> . NAT 


irV-i (err' nn IP 

LUC1 ^sre OD lr 


remote GW and 


srcIP obtained from 


addr od outbound) 


hosts (same 


user client pair, 




motivation as 


Local Client id . 




conventional 






NAT). 






1 A.imVt ID 

L. AV01U lr 






address con- 






flict with 






remote GW and 






its networks 






(new potential 






problem created 






by VPN). 






Hence, a pool 






may be 






associated with 






each remote ID. 




c. *R' Connec- 


Avoid IP addr 


"MAP destIP TO yes 


tions translate 


conflict with 


<vaiue from pool>". 




remote GW and 


NAT destIP obtained 


addr on in -bound). 


its networks 


from ISAKMP IDci. 




(new potential 






problem created 






by VPN). 






Hence, a pool 






may be 






aaaUCLHLCU WILLI 






each remote ID. 




d. 'R* connec- 


1. Provide a 


"MAP srcIP TO yes 


tions, translate 


form of load 


<value from pool>". 


IDcr (dest IP 


shariDg from 


NAT srcIP obtained 


addr on in-bound). 


single external, 


from ISAKMP IDcr. 




globally rout- 






able IP address 






to a set of 






servers. 






2. Hide own IP 






addresses 






behind external 






address. 






Hence, a pool 






may be 






associated with 






a globally 






routable IP 






address (IDcr). 





In step 24, initiator mode connections are started. When 
starting an initiator mode connection, the connection man- 
ager checks if the local client ID is to be translated. If so, the 
connection manager looks for an available IP address from 
NAT pool, say 52, associated with a remote ID in the 
database. Availability is determined by the connection man- 
ager as follows; it maintains a single (system-wide, since 
connection manager runs once per system) list of IP 
addresses that have been used in some active connection 
Estates: starting, running or stopped) from any a-type pool 
(see Table 1). The first IP address in the pool not in the used 
list, is chosen, and added to the used list. If an available IP 
address cannot be found, the connection is not started and an 
appropriate error message (and possibly return code to the 
OP NAV GUI) is generated. The policy database is not 
updated to show an IP address is in use — rather this is 
determined dynamically by the connection manager based 
solely on its set of active connections. 

The start message (msg) sent by connection manager to 
ISAKMP (aka IKE) will have NAT rhs IP address selected 
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20 
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30 



35 



40 



45 



50 



55 



60 



65 



from the pool. The NAT rhs IP address is added to the SA 
pair, which is completed by the returned SAs from ISACMP 
(or, IKE). Connection manager then loads the connection to 
IPSec. Thus, in the general case, as also in the special case 
of VPN NAT, a tunnel NAT rule is both defined 
(automatically or manually) and applied to a tunnel endpoint 
(which is a local or remote IP address) to generate from a 
NAT address pool a NAT address for use thereafter when the 
tunnel is setup, negotiated and used. 

IPSec generates NAT rules for the two SAs. On outbound, 
NAT will occur after filtering and before IPSec and on 
inbound, NAT will occur after IPSec (and before filtering). 
In this case, NAT is wrapping the local end of the IPSec 
connection. 

Referring to FIGS. 3 and 4, conventional NAT functions 
are illustrated for background and contrast with later figures 
which show VPN NAT types according to the invention. 

Referring to FIG. 3, static is the simplest form of NAT. 
Both conventional NAT types are explicitly configured by 
the user by writing the corresponding NAT rule statements 
via the OpNat GUI. This is in contrast to the IPSec NAT, in 
which the actual NAT rules or statements are generated by 
the system. The MAP statement <MAP lhs TO rhs> and 
HIDE statement <HIDE ip addr set BEHIND rhs> are such 
statements. 

Again referring to FIG. 3, on inbound processing, if 
source ip 70 matches lhs 72 in the MAP lhs TO rhs 
statement, then sre ip 70 is translated to rhs 76. On outbound 
processing, if destination ip 74 matches rhs 76, then desti- 
nation ip 74 is translated to lhs 72. 

Referring to FIG. 4, masquerade NAT (also referred to as 
network address and port translation (NAPT)), uses the 
HIDE statement, supra, and provides many-to-one address 
translation by using its own port pools 118 (UDP, TCP) to 
remember how to translate the inbound traffic. Unlike static 
NAT (FIG. 3), masquerade NAT conversations CONVER- 
SATION sre ip, sre port, rhs. ip, rhs port, . . . > can only be 
initiated by internal (lhs) addresses. VPN NAT, a name used 
to identify the preferred embodiment of the present 
invention, as will be seen, is closer to static NAT, in that it 
does not include port translation. 

Referring further to FIG. 4, in processing outbound 
datagrams, in step <1> if source ip address 90 is in the ip 
address set 92 of the HIDE statement, then in step <2> the 
CONVERSATION is set up by copying sre ip 90 into 
CONVERSATION field 94, in step <3> source port 98 into 
field 96, in step <4> rhs 104 into field 100, and in step <5> 
the rhs port into field 102 from the correct pool in port pools 
118. Then, in step <6> source ip 90 is translated to rhs 104, 
and in step <7> source port 98 is changed to rhs port 102. 
In processing inbound datagrams, if in step <8> destination 
ip address 106 and destination port 108 match CONVER- 
SATION fields-rhs ip 100 and rhs port 102, respectively, 
then in step <9> destination ip address 106 is translated to 
CONVERSATION source ip address 94 and in step <10> 
destination port 108 is translated to CONVERSATION 
source port 96. 

Some special situations also handled by NAT are not 
illustrated because they are of no interest to the present 
invention. These include handling of special situations cre- 
ated by FTP or ICMP, both of which contain IP address that 
are translated. Checksum re-calculation is done. In masquer- 
ade NAT once a conversation exists, later datagrams are 
matched against that, rather than the original (precipitating) 
HIDE rule, the port pools are managed, conversations are 
timed and terminated, and ports are mapped. It is a particular 



07/15/2004, EAST Version: 1.4.1 



US 6,615,357 Bl 

7 8 

advantage of the invention that VPN NAT supports I CMP lhs 186. In step <0>, after ISAKMP negotiations are com- 

and FTP (including the famous 0 FTP PORT command and pie ted using rhs 184, implicit MAP rule 190 is loaded. When 

attendant problems). processing inbound datagrams, if in step <1> destination ip 

Referring to FIG. 5, the preferred embodiment of the 200 matches rhs 198, in step <2> destination ip 200 is 

invention for VPN NAT type 'a' is illustrated. In VPN NAT, 5 translated to lhs 196. When processing outbound datagrams, 

type 'a\ IDci is translated for initiator-mode conversations. if in step <3> source ip 192 matches lhs 196, in step <4> 

After system generated implicit NAT rule 128 <MAP lhs TO source ip 192 is translated to rhs 198. 

rhs> is loaded, it functions as static NAT. The key to making In step 28, when the connection manager gets SA pair 

this work, is that the security associations negotiated by updates, it copies any NAT IP addresses in existing SA pairs 

ISAKMP use the implicit MAP 130 rhs 138. Hence, the SAs 10 to the new SA pair. 

and the VPN NAT are synchronized. in step 30, when ending a connection, the connection 

Referring further to FIG. 5, for a locally initiated manager frees (makes available) any NAT IP addresses 

conversation, in step <-2>, since NAT is requested, implicit associated with the connection. NAT IP addresses are 

MAP rule 128 is created by copying local client ID 122 to removed from the appropriate list maintained by the con- 

lhs 126 and the ip address 120 is obtained from the appro- 15 nection manager. 

priate pool and copied to rhs 124. In step <0>, after Advantages Over the Prior Art 

ISAKMP negotiation is complete using rhs 124, implicit Advantages Uver me F nor Art 

MAP rule 130 is loaded. For outbound processing, if in step It is an advantage of the invention that there is provided 

<1> src ip 132 matches lhs 136, then in step <2> src ip is an improved system and method for concurrently imple- 

translated to rhs 138. For inbound processing, if in step <3> 20 menting both Network Address Translation (NAT) and IP 

dest ip address 140 matches rhs 138, then in step <4> Security (IP Sec). 

destination ip 140 is translated to lhs 136. It is a further advantage of the invention that there is 

In step 26, responder mode connections are started. In so provided a system and method for solving the increased 

doing, ISAKMP functions negotiates the SAs based on likelyhood of IP address conflicts inherent in the use of a is 

currently configured policy. When done, they are sent to the 25 virtual private network (VPN). 

connection manager as a SA collection of 1 to n SA pairs. It is a further advantage of the invention that there is 

The connection manager, upon receiving the start mes- provided a system and method for enabling utilization of 

sage (msg) from ISAKMP, looks at the connection definition VPNs without requiring re-addressing a domain (a expen- 

in the database and checks the IDcr and IDci NAT flags. If 3Q sive alternative). 

NAT remote flag is 'on', then an IP address is obtained from It is a further advantage of the invention that there is 

the appropriate NAT pool associated with the remote ID. If provided a system and method for VPN NAT which is 

the NAT local flag is 'on', then an IP address is obtained accomplished entirely in the IP Sec gateway without require 

from the pool associated with IDcr (a global address). In changes in domain hosts. 

FIGS. 6 and 7, VPN NAT types 'c' and 'd' are illustrated. ^$ It is a further advantage of the invention that there is 

Management of IP address availability from the remote ID provided a system and method for VPN NAT which requires 

pool is done by the connection manager based on its set of no, or only minor changes to routing, in each connected 

active connections (as for type ' a* VPN NAT). Connection domain. 

manager also handles availability for the IDcr pool, which It is a further advantage of the invention that there is 

allows load balancing. The IDcr pool is a set of IP addresses 40 provided a system and method for VPN NAT which is 

for nat'ing IDcr. There are two basic approaches: (1) for simple to configure. 

every start search the pool from the first entry; or, (2) for i t i s a further advantage of the invention that there is 

every start, the pool is searched from the last used IP. provided a solution to the address collision problems caused 

The load to IPSec occurs as in the initiator mode case by VPNs, 
above. When processing R-type connection traffic (in con- 45 

nection name, first byte of serial is "R"), two address Alternative Embodiments 

translations may occur for each inbound and outbound It will be appreciated that, although specific embodiments 

packet (source and destination). of the invention have been described herein for purposes of 

Referring to FIG. 6, VPN NAT type 'c' executes to illustration, various modifications may be made without 

translate IDci for responder-mode conversations as follows: 50 departing from the spirit and scope of the invention. In 

in step <-2>, for remotely initiated conversations, at start, particular, it is within the scope of the invention to provide 

since NAT is requested, implicit MAP rule 158 <MAP ihs a program storage or memory device such as a solid or fluid 

TO rhs> is created, copying IDci 152 to rhs 154. In step transmission medium, magnetic or optical wire, tape or disc, 

<-l>, the ip address is obtained from the appropriate pool or the like, for storing signals readable by a machine for 

150 and copied to lhs 156. In step <0>, after ISAKMP 55 controlling the operation of a computer according to the 

negotiation is complete using rhs 154, implicit rule 160 is method of the invention and/or to structure its components 

loaded. When processing inbound datagrams, if in step <1> in accordance with the system of the invention, 

src ip 172 matches rhs 168, in step <2> source ip 172 is Accordingly, the scope of protection of this invention is 

translated to lhs 166. When processing outbound datagrams, limited only by the following claims and their equivalents, 

if in step <3> destination 164 matches lhs 166, in step <4> 60 We claim: 

destination ip 164 is translated to rhs 168. 1. A method of operating one or more tunnels of nested 

Referring to FIG. 7, VPN NAT type 'd* executes to protocols that integrate network address translation (NAT) at 

translate IDcr for responder-mode conversations as follows: an Internet Protocol (IP) layer, comprising the steps of: 

in step <-2>, for remotely initiated conversations, at start, configuring a tunnel NAT IP address pool; 

since NAT requested, implicit MAP rule 188 is created, 65 independently configuring one or more tunnels in a virtual 

copying IDcr 182 to rhs 184. In step <-l>, the ip address is private network to utilize tunnel NAT at one or both of 

obtained from appropriate address pool 180 and copied to a local and a remote tunnel endpoint; 
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upon starting an instantiation of a tunnel, selectively 
automatically generating a specific tunnel NAT rule or 
using a configured tunnel NAT rule as an instantiation - 
specific tunnel NAT rule for said instantiation; 

applying said instantiation-specific NAT rule to a local or 5 
remote IP address to generate a NAT address from said 
NAT IP address pool; 

using said NAT address, negotiating tunnel configuration 
and operational parameters between tunnel endpoints; 

loading said operational parameters into an operating 
system kernel, said operational parameters including 
said instantiation-specific tunnel NAT rule; and 

processing packet traffic as it enters and exits said local 
tunnel endpoint by applying said instantiation-specific 35 
tunnel NAT rule to each packet. 

2. A system for operating one or more tunnels of nested 
protocols that integrate network address translation (NAT) at 
an Internet Protocol (IP) layer, comprising: 

means for configuring a tunnel NAT IP address pool; 20 

means for independently configuring one or more tunnels 
in a virtual private network to utilize tunnel NAT at one 
or both of a local and a remote tunnel endpoint; 

means for selectively automatically generating upon start- 
ing an instantiation of a tunnel a specific tunnel NAT 25 
rule or using a configured tunnel NAT rule as an 
instantiation-specific tunnel NAT rule for said instan- 
tiation; 

means for applying said instantiation-specific NAT rule to 3Q 

a local or remote IP address to generate a NAT address 

from said NAT IP address pool; 
means responsive to said NAT address for negotiating 

tunnel configuration and operational parameters 

between tunnel endpoints; 



means for installing said tunnel instantiation including 
said operational parameters in an operating system 
kernel, said operational parameters including said 
instantiation-specific tunnel NAT rule; and 

means for processing packet traffic as it enters and exits 
said local tunnel endpoint by applying said 
instantiation -specific tunnel NAT rule to each packet. 

3. A program storage device readable by a machine, 
tangibly embodying a program of instructions executable by 
a machine to perform method steps for operating one or 
more tunnels of nested protocols that integrate network 
address translation (NAT) at an Internet Protocol (IP) layer, 
said method steps comprising: 

configuring a tunnel NAT IP address pool; 

independently configuring one or more tunnels in a virtual 
private network to utilize tunnel NAT at one or both of 
a local and a remote tunnel endpoint; 

upon starting an instantiation of a tunnel, selectively 
automatically generating a specific tunnel NAT rule or 
using a configured tunnel NAT rule as an instantiation- 
specific tunnel NAT rule for said instantiation; 

applying said instantiation-specific NAT rule to a local or 
remote IP address to generate a NAT address from said 
NAT IP address pool; 

using said NAT address, negotiating tunnel configuration 
and operational parameters between tunnel endpoints; 

loading said operational parameters into an operating 
system kernel, said operational parameters including 
said instantiation-specific tunnel NAT rule; and 

processing packet traffic as it enters and exits said local 
tunnel endpoint by applying said instantiation-specific 
tunnel NAT rule to each packet. 
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